[ESS] emacs hangs / freezes when R hangs

Martin Maechler 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> http://gist.github.com/612541
    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;
    >> 4+4;
    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
long.
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
side.
Please consider using   M-x ess-submit-bug-report  
to send your detailed configuration at the time of the bug to us
ESS developers.


    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.

(which was?)

    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
    >>>  and
    >>> * 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?
    >> 
    >> http://gist.github.com/
    >> 
    >> (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
    >> like.
    >> 
    >> Cheers,
    >> -steve
    >> 
    >>> 
    >>> 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.
    >>> 
    >>> Regards
    >>>  Lars
    >>> 
    >>> ______________________________________________
    >>> ESS-help at stat.math.ethz.ch mailing list
    >>> https://stat.ethz.ch/mailman/listinfo/ess-help
    >>> 
    >>> 
    >> 
    >> 
    >> 
    >> --
    >> 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> -- 
    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> http://www.ismll.uni-hildesheim.de

    LS> ______________________________________________
    LS> ESS-help at stat.math.ethz.ch mailing list
    LS> https://stat.ethz.ch/mailman/listinfo/ess-help



More information about the ESS-help mailing list