[ESS] Running R and Splus from ESS.

[Martin Maechler]

Dear Gerald,

>>>>> "gj" == gerald jean <gerald.jean at dgag.ca>
>>>>>     on Mon, 13 Sep 2010 15:17:36 -0400 writes:

    gj> Hello,

    gj> I did post on this subject a little while ago, I didn't get any response.
    gj> I realized after posting that my timing was pretty bad, right in the middle
    gj> of the R-users conference! so I try again.

    gj> I am running ESS-5.11 under Emacs 22.3 on a Linux 64-bit box.  I often have
    gj> a ".q" file linked to an Splus process and a ".R" file linked to an R
    gj> process at the same time.  I have been doing this for quite some time with
    gj> no problem.

    gj> Since I upgraded ESS to 5.11 Emacs seems to get confused with what is going
    gj> on and eventually it freezes, every time. The only way I found to get out
    gj> of this is to kill Emacs.

That's definitely very unfortunate.
(As an R Core member) I'm often using several versions of R simultaneously
and having differnt .R files "linked" to these R processes, and
change the "links", etc.
But I don't think I have ever experienced anything like the
problem you describe.


    gj> I also have another problem, which might be related, under ESS-5.11 it is
    gj> very hard to get rid of an R process.  I kill the R process with C-c C-q,
    gj> reply to the question about saving the workplace.  Then R quits normally,
    gj> but as soon as I start moving in the "*.R" buffer ESS starts a new
    gj> R-process, I don't want this, I just
    gj> want to browse my R-code.  Same thing happens when I want to shut down
    gj> everything, first the R-process, if one is running, then Emacs (if nothing
    gj> else is running) but after the R-process normally closes down I can't save
    gj> the "*.R" buffer without R restarting, I usually end up getting Emacs to
    gj> kill the R-process as it shuts down.  This behaviour doesn't happen with
    gj> the
    gj> Splus-processes?  This is pretty anoying. 
    gj>  Anyone has a clue of what is happening?

Well, there *is* code in ESS that starts an R process for the
user >>> when it is desired <<<
E.g. if you are in the *.R buffer and want to evaluate code, and
there is no R process, one is started for you,
instead of just signalling an 
	 "Error: there is no R process .."

So, the problem must stem from this feature.
Has anyone else seen similar *un*desired start up of R?

Gerald,
you may also consider   M-x ess-submit-bug-report
to send us all the details of the state of your ESS.

Regards,
Martin