[ESS] emacs hangs / freezes when R hangs
schmidt-thieme at ismll.de
Wed Oct 6 02:05:17 CEST 2010
the two files are also available from
now. Thanks for letting me know they did not make it through the list!
I just tried with a "vanilla" emacs and the original ess (to make sure there
is not some stupid configuration in my .emacs causing the problem).
You are right, evaluating a single line (ess-eval-line) works to some extent
-- I still can edit in parallel. Ctrl-g also stops the computation in
R, but afterwards
I cannot send anything to R anymore.
With two lines, e.g. ess-eval-region on
> while (T) 1+1;
emacs hangs for me - I cannot evaluate anything in parallel. I can get
with ctrl-g, but as above, afterwards R does not accept any new input.
If ctrl-g works better for you: are you evtl. using Windows? Because as far
as I understand ess there another solution is used (which probably does not
suffer from the problems described).
All these problems go away with the proposed approach.
That evaluation is stopped once you have to quit an endless loop, I would say
is correct/desired behavior: when something goes wrong, you usually do not
want the computation evtl. based on these earlier results to be continued.
Also my code will do so.
On Wed, Oct 6, 2010 at 12:52 AM, Steve Lianoglou
<mailinglist.honeypot at gmail.com> wrote:
> Hi Lars,
> On Mon, Oct 4, 2010 at 7:52 PM, Lars Schmidt-Thieme
> <schmidt-thieme at ismll.de> wrote:
>> Dear ess maintainers,
>> if you evaluate a line or region in R (ess-eval-line/region), in the current
>> implementation emacs waits for R to complete. This means esp. that
>> * you cannot continue to edit while R is computing something concurrently
>> * if R hangs (e.g., in an infinite loop), emacs hangs / freezes and it is
>> difficult to interrupt R.
> Thanks for offering a way to handle these issues, two things:
> (1) It doesn't look like your attachments came through to the mailing
> list -- perhaps they're not allowed? Maybe you can pry posting a gist?
> (2) In certain situations, ctrl-g does the trick you're after. The one
> case I find it doesn't work to my "satisfaction" is when I'm
> evaluating a large region of code. In my experience with these cases,
> if there is a long running function call, ctrl-g will in fact return
> control to emacs, but it will also stop evaluation when the long
> running function returns -- it won't continue to the next line.
> Using ctrl-g when I C-c C-l (run an entire file) works just fine,
> though. It also works fine when I just call a long running function by
> itself ...
> Just thought I'd bring that to your attention if you weren't aware of
> it already, though I'm also curious to see what your solutions look
>> This behavior has been reported by several users in the past and can
>> be easily reproduced by evaluating
>>> while (T) 1+1;
>> Attached is a proposal how to change this behavior so that emacs is no
>> longer waiting for R to complete, but sends the code to R (still line
>> by line, so input and output still will be nicely aligned), and then
>> lets the user continue to edit files.
>> * ess-inf.el is taken from ess 5.7.1 release (as packaged for ubuntu)
>> and all places where I changed things have been marked.
>> * linefeeder.el is a generic solution for sending input line-by-line to
>> comint processes.
>> To test it: just replace ess-inf.el in ess 5.7.1 by the version attached
>> and add linefeeder.el to the ess lisp directory, then run ess-eval-region
>> in an R buffer. I tested it with Gnu Emacs 23.1.1, R 2.10.1 and ess 5.7.1
>> on Linux.
>> If you could give it a try and consider it for integration in an upcoming
>> ess release, I would be very happy. Feel free to take the bits you
>> think are useful.
>> The idea is very simple: instead of chopping the code into lines
>> and feeding it line-by-line in the main edit thread (ess-eval-linewise),
>> one sends just a single line and ends activity in this thread,
>> catching the next R prompt through a comint-output-filter-function
>> and then sending the next line.
>> ESS-help at stat.math.ethz.ch mailing list
> Steve Lianoglou
> Graduate Student: Computational Systems Biology
> | Memorial Sloan-Kettering Cancer Center
> | Weill Medical College of Cornell University
> Contact Info: http://cbio.mskcc.org/~lianos/contact
Prof. Dr. Dr. Lars Schmidt-Thieme
Information Systems and Machine Learning Lab (ISMLL)
Institute of Computer Science,
University of Hildesheim, Germany
post address: Marienburger Platz 22, 31141 Hildesheim, Germany
visitor address: Samelsonplatz 1, D-31141 Hildesheim, Germany
Tel. (+49) 05121 / 883-851 (direct), -850 (secretary), -859 (fax)
More information about the ESS-help