I've had time to return to the "external editor" project. The
following
function does almost what I want, which is to allow an external editor to
feed command lines to R.
ext.editor<-function(editor) {
ext.input<-pipe(editor,"r")
eval(parse(ext.input))
close(ext.input)
}
While the description of parse() indicates that it should parse input line by
line, the output of the editor is not read until it exits. The external
editor is sending the output as requested, so I must be using the wrong
connection setup. Any hints?
Jim
Feel free to ignore any garbage below this line.
UTS CRICOS Provider Code: 00099F
DISCLAIMER\ ====================================================... [[dropped]]
On Mon, 24 Mar 2003, Jim Lemon wrote:> I've had time to return to the "external editor" project. The following > function does almost what I want, which is to allow an external editor to > feed command lines to R. > > ext.editor<-function(editor) { > ext.input<-pipe(editor,"r") > eval(parse(ext.input)) > close(ext.input) > } > > While the description of parse() indicates that it should parse input line by > line, the output of the editor is not read until it exits. The external > editor is sending the output as requested, so I must be using the wrong > connection setup. Any hints??parse says `parse' returns the parsed but unevaluated expressions in a list. Each element of the list is of mode `expression'. that is, it takes all the input and returns a list once all the input has been parsed. There is no multi-tasking in the R evaluator, and you have no loop in your code, so eval can only be called once when parse exits. I am not clear what you actually want. If it is to repeatedly send a block of code to R and get that block evaluated then you need to indicate the end of the block somehow, split the pipe stream up into blocks and run a loop to parse and evaluate each block. If you want to simulate the command-line, the easiest way to do this is to submit to the command line, and to help with that you would have to at least tell us your platform! -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595
ripley at stats.ox.ac.uk wrote:> ?parse says > > `parse' returns the parsed but unevaluated expressions in a list. > Each element of the list is of mode `expression'. > > that is, it takes all the input and returns a list once all the input > has been parsed. There is no multi-tasking in the R evaluator, and you > have no loop in your code, so eval can only be called once when parse > exits. > > I am not clear what you actually want. If it is to repeatedly send a > block of code to R and get that block evaluated then you need to > indicate the end of the block somehow, split the pipe stream up into > blocks and run a loop to parse and evaluate each block. If you want to > simulate the command-line, the easiest way to do this is to submit to > the command line, and to help with that you would have to at least tell > us your platform!My apologies. OS - Linux (RedHat 7.2) I had read the section in the R Language Manual about parsing: "The read-eval-print loop forms the basic command line interface to R. Textual input is read until a complete R expression is available." The initial aim is to send selected text from the editor to the R command line. If I manually invoke the editor from a terminal, I can do exactly this, with each section of text appearing as if entered when sent from the external editor. However, your suggestion about blocking is probably the answer, as I noticed the blocking option but decided that the explanation on the help page for "connections" implied that a non-blocking mode would be the correct one: "In non-blocking mode, operations return as soon as possible, so on input they will return with whatever input is available..." Any suggestions would be greatly appreciated. Jim
Hi again,
If my trawling through the "connections" code is correct, a pipe
connection is designed to read to EOF before returning its input to the
parsing function. Blocking is not an option with this type of connection.
As I do not know how to spoof an EOF on an open pipe, it looks like I
would have to rewrite 3 or 4 fairly low level functions to return input on
EOL.
My impression is that this is the wrong way to go about this. After all, I
am sure that something similar is already being done using the present
connection functions. Any suggestions as to where else I might look would
be greatly appreciated.
OS - Linux
R v1.5.1
To reiterate, what I am attempting to do is to send selected text from an
external editor to the R command line, where it will be processed as if
entered from the keyboard. I have accomplished everything except getting
the selections of text which are sent from the external editor to be
processed individually rather than all in a bunch when the external editor
exits. For example:
Select the following text in the editor and send it:
cat("Mean of x\n")
x<-1:10
mean(x)
R shows:
Mean of x
[1] 5.5
Select more text and send it:
cat("Sum of x\n")
sum(x)
R shows:
Sum of x
[1] 55
What happens now - selections are sent, but nothing happens until the
external editor is closed, at which point, R shows:
Mean of x
[1] 5.5
Sum of x
[1] 55
Thanks,
Jim
If you are not trying to write R editing functionality for an editor
other than (X)Emacs or WinEdt, what you describe below is already
available in these editors using ESS with (X)Emacs and R macros for
WinEdt. <br>
<br>
John Fox''s enhancements for using ESS with Xemacs at page below. You
can also use ESS alone, without these enhanced menus, etc.<br>
<a class="moz-txt-link-freetext"
href="http://www.socsci.mcmaster.ca/jfox/Books/Companion/ESS/">http://www.socsci.mcmaster.ca/jfox/Books/Companion/ESS/</a><br>
<br>
Look at Editing Support section on the following CRAN page.<br>
<a class="moz-txt-link-freetext"
href="http://cran.r-project.org/other-software.html">http://cran.r-project.org/other-software.html</a><br>
<br>
<span type="cite">Jim Lemon wrote:</span>
<p> </p>
<blockquote type="cite" > <tt>
Hi again, <br>
<br>
If my trawling through the "connections" code is correct, a pipe
<br>
connection is designed to read to EOF before returning its input to
the<br>
parsing function. Blocking is not an option with this type of
connection. <br>
As I do not know how to spoof an EOF on an open pipe, it looks like I <br>
would have to rewrite 3 or 4 fairly low level functions to return input
on <br>
EOL. <br>
<br>
My impression is that this is the wrong way to go about this. After
all, I <br>
am sure that something similar is already being done using the present
<br>
connection functions. Any suggestions as to where else I might look
would <br>
be greatly appreciated. <br>
<br>
OS - Linux <br>
R v1.5.1 <br>
<br>
To reiterate, what I am attempting to do is to send selected text from
an <br>
external editor to the R command line, where it will be processed as
if<br>
entered from the keyboard. I have accomplished everything except
getting <br>
the selections of text which are sent from the external editor to be <br>
processed individually rather than all in a bunch when the external
editor <br>
exits. For example: <br>
<br>
Select the following text in the editor and send it: <br>
<br>
cat("Mean of x\n") <br>
x<-1:10 <br>
mean(x) <br>
<br>
R shows: <br>
<br>
Mean of x <br>
[1] 5.5 <br>
<br>
Select more text and send it: <br>
<br>
cat("Sum of x\n") <br>
sum(x) <br>
<br>
R shows: <br>
<br>
Sum of x <br>
[1] 55 <br>
<br>
What happens now - selections are sent, but nothing happens until the <br>
external editor is closed, at which point, R shows: <br>
<br>
Mean of x <br>
[1] 5.5 <br>
Sum of x <br>
[1] 55 <br>
<br>
<br>
Thanks, <br>
<br>
Jim <br>
<br>
______________________________________________ <br>
<a class="moz-txt-link-abbreviated"
href="mailto:R-help@stat.math.ethz.ch">R-help@stat.math.ethz.ch</a>
mailing list <br>
<a
href="https://www.stat.math.ethz.ch/mailman/listinfo/r-help">https://www.stat.math.ethz.ch/mailman/listinfo/r-help</a>
<br>
</tt> </blockquote>
On Sun, 30 Mar 2003, Jim Lemon wrote:> If my trawling through the "connections" code is correct, a pipe > connection is designed to read to EOF before returning its input to the > parsing function. Blocking is not an option with this type of connection.Not so: it is parse(file=) that is designed to read to EOF. pipe() does nothing, but reading from a pipe reads connections however much is asked for. If you want non-blocking, use a socket or fifo.> As I do not know how to spoof an EOF on an open pipe, it looks like I > would have to rewrite 3 or 4 fairly low level functions to return input on > EOL. > > My impression is that this is the wrong way to go about this. After all, I > am sure that something similar is already being done using the present > connection functions. Any suggestions as to where else I might look would > be greatly appreciated.I have already sent you such a reply, on Monday 24th. -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595
In a message dated 3/31/03 6:32:45 AM Eastern Standard Time, bitwrit@ozemail.com.au writes:> AT wrote: > >If you are not trying to write R editing functionality for an editor > >other than (X)Emacs or WinEdt, what you describe below is already > >available in these editors using ESS with (X)Emacs and R macros for > >WinEdt. > > Well, in fact, I am trying to use the functionality already present in > NEdit, which is in my opinion a pretty good editor. Thanks for the tip > about WinEdit - I will follow it upIt is WinEdt NOT WinEdit (that is another editor). Another tip---R macro installation for WinEdt asks you to use its initialization file that makes R components possible. I had trouble configuring it with earlier my configuration of WinEdt, so I created another instance (desktop Icon) of WinEdt that uses R initialization file, while keeping the old configuration for other work.> >John Fox''s enhancements for using ESS with Xemacs at page below. You > >can also use ESS alone, without these enhanced menus, etc. > > Couldn''t find much about how ESS actually does the trick. Either this is a > very difficult thing to do or it is quite easy but very difficult to find > out about. I lean toward the latter at the momentEmacs or Xemacs are needed as editors to use ESS (Emacs Speaks Statistics) <A HREF="http://www.gnu.org/software/emacs/windows/ntemacs.html">http://www.gnu.org/software/emacs/windows/ntemacs.html</A> <A HREF="http://www.xemacs.org/">http://www.xemacs.org/</A> Once (X)Emacs is installed, ESS can be installed from the following site. <A HREF="http://software.biostat.washington.edu/statsoft/ess/">http://software.biostat.washington.edu/statsoft/ess/</A> When a file with *.R extension is opened in (X)Emacs with ESS installed, either the menus or keyboard commands can be used to send the current line, region (block of lines), file, etc., to the running R process. R process can be started with ''Meta-x R Ret''. Usually the Esc key on windows keyboards is assigned to ''Meta'', but this can be changed. Once (X)Emacs and ESS are installed, it is quite easy. Really. (X)Emacs, ESS combination is quite good on windows, and also works on Linux, Unix, etc. It can also be used for other statistical programming like SAS, Stata, etc, a major advantage over WinEdt. WinEdit has some very useful features for using LaTeX, and other programming, but current configuration for using R needs changes to get to the level of (X)Emacs--ESS combination (for instance, the R window can not be minimized while sending commands to it, occupying precious screen-space). A little reading at the above sites should give a pretty good idea of trade-offs and functionality. Hope this helps. [[alternate HTML version deleted]]
On Mon, 31 Mar 2003 TyagiAnupam at aol.com wrote:> In a message dated 3/31/03 6:32:45 AM Eastern Standard Time, > bitwrit at ozemail.com.au writes: > > > AT wrote: > > >If you are not trying to write R editing functionality for an editor > > >other than (X)Emacs or WinEdt, what you describe below is already > > >available in these editors using ESS with (X)Emacs and R macros for > > >WinEdt. > > > > Well, in fact, I am trying to use the functionality already present in > > NEdit, which is in my opinion a pretty good editor. Thanks for the tip > > about WinEdit - I will follow it up > > It is WinEdt NOT WinEdit (that is another editor). > > Another tip---R macro installation for WinEdt asks you to use its > initialization file that makes R components possible. I had trouble > configuring it with earlier my configuration of WinEdt, so I created another > instance (desktop Icon) of WinEdt that uses R initialization file, while > keeping the old configuration for other work. > > > >John Fox''s enhancements for using ESS with Xemacs at page below. You > > >can also use ESS alone, without these enhanced menus, etc. > > > > Couldn''t find much about how ESS actually does the trick. Either this is a > > very difficult thing to do or it is quite easy but very difficult to find > > out about. I lean toward the latter at the momentI think the `trick'' is how text for parsing is sent to R, and the answer is via the command line, using C redirection (and ptys under Unix). I''ve already suggested that approach a week ago. This thread is getting very bitty, and I am still waiting for a clear statement of what it is that Jim is trying to achieve. It sounds as if using redirection (and the -ess flag under Windows) is what is required. -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595
"Prof. Brian Ripley" <ripley at stats.ox.ac.uk> writes:> I think the `trick'' is how text for parsing is sent to R, and the answer > is via the command line, using C redirection (and ptys under Unix). > I''ve already suggested that approach a week ago.Yes. As far as I know, ESS sits on top of the "comint" layer, which is a body of code that is designed to run any stdio program from within emacs. So you don''t just have to clone ESS, but also whatever comint does on Windows (which is likely nontrivial).> This thread is getting very bitty, and I am still waiting for a clear > statement of what it is that Jim is trying to achieve. It sounds as if > using redirection (and the -ess flag under Windows) is what is required.-- or setReader(), except that that doesn''t exist in R (yet?). You *might* be able to fake something like that using fileevents in Tcl, but don''t come to me if you can''t get it to work... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /''_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
A.J. Rossini writes:> From: rossini at blindglobe.net [mailto:rossini at blindglobe.net] > Sent: Tuesday, April 01, 2003 1:28 PM > To: r-help at stat.math.ethz.ch > > "Prof. Brian Ripley" <ripley at stats.ox.ac.uk> writes: > > > I think the `trick' is how text for parsing is sent to R, > and the answer > > is via the command line, using C redirection (and ptys under Unix). > > I've already suggested that approach a week ago. > > This is exactly it -- ESS works by sitting on top of R's I/O streams, > i.e. stdin and stdout, and parsing the input and output of known > commands. Why anyone would want to reinvent that wheel is beyond me. >Perhaps because some people (myself included) find Emacs a really unpleasant editor to use. (Not implying this is the case for the person who started this thread, however.) I know it is hard for the Emacs zealots to comprehend. Having the ability to pipe selections from, say Nedit, directly to the R command line would be nice. It's absence is not enough to make me switch editors though. Rich Raubertas ------------------------------------------------------------------------------