[ESS] emacs hangs / freezes when R hangs
maechler at stat.math.ethz.ch
Wed Oct 20 10:09:52 CEST 2010
>>>>> "LS" == Lars Schmidt-Thieme <schmidt-thieme at ismll.de>
>>>>> on Wed, 6 Oct 2010 11:05:17 +1100 writes:
LS> Dear Steve,
LS> the two files are also available from
LS> now. Thanks for letting me know they did not make it through the list!
LS> I just tried with a "vanilla" emacs and the original ess (to make sure there
LS> is not some stupid configuration in my .emacs causing the problem).
LS> You are right, evaluating a single line (ess-eval-line) works to some extent
LS> -- I still can edit in parallel. Ctrl-g also stops the computation in
LS> R, but afterwards
LS> I cannot send anything to R anymore.
LS> With two lines, e.g. ess-eval-region on
>> while (T) 1+1;
LS> emacs hangs for me - I cannot evaluate anything in parallel. I can get
LS> emacs back
LS> with ctrl-g, but as above, afterwards R does not accept any new input.
Hmm, I'm one of the ESS co-authors and have been using versions
of Unix, i.e. Linux nowadays, for about 22 years now,
and been using ESS and its predecessor ("S-mode") for almost as
I've always used C-g (aka "ctrl-g") and I think I have never
seen the problem
"afterwards R does not accept any new input"
This must be a bugous or "infelicitous" configuration on your
Please consider using M-x ess-submit-bug-report
to send your detailed configuration at the time of the bug to us
LS> If ctrl-g works better for you: are you evtl. using Windows? Because as far
LS> as I understand ess there another solution is used (which probably does not
LS> suffer from the problems described).
Well, in my eyes and experience, Windows has rather *more* than
*less* problems with ESS and R than Linux ...
LS> All these problems go away with the proposed approach.
LS> That evaluation is stopped once you have to quit an endless loop, I would say
LS> is correct/desired behavior: when something goes wrong, you usually do not
LS> want the computation evtl. based on these earlier results to be continued.
LS> Also my code will do so.
LS> - Lars
LS> On Wed, Oct 6, 2010 at 12:52 AM, Steve Lianoglou
LS> <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
LS> Prof. Dr. Dr. Lars Schmidt-Thieme
LS> Information Systems and Machine Learning Lab (ISMLL)
LS> Institute of Computer Science,
LS> University of Hildesheim, Germany
LS> post address: Marienburger Platz 22, 31141 Hildesheim, Germany
LS> visitor address: Samelsonplatz 1, D-31141 Hildesheim, Germany
LS> Tel. (+49) 05121 / 883-851 (direct), -850 (secretary), -859 (fax)
LS> ESS-help at stat.math.ethz.ch mailing list
More information about the ESS-help