[ESS-bugs] ESS 13.09-1 with old R versions fails pretty badly

[Martin Maechler]

Thank you Vitalie, for this careful reply,
sorry for the delay in reply .. (but then are on US Western
time, so no big problem for you, right ?)

>>>>> Vitalie Spinu <spinuvit at gmail.com>
>>>>>     on Wed, 30 Oct 2013 13:22:44 -0700 writes:

    >>>> Martin Maechler on Wed, 30 Oct 2013 09:57:59 +0100
    >>>> wrote:

    > [...]

    >> and sorry, but I've come to the conclusion that I very
    >> strongly would like us to revert from ESSR package to the
    >> way ESS 13.09 worked.

    > Let's do that, but with a notable difference. See below.

    > [...]


    >> The advantage of having such non-repository package over
    >> what we've had in 13.09 seems really small to me, - speed
    >> in loading, once the package is installed for the correct
    >> version of R - (one help page which still has to be
    >> complemented by ESS documentation) compared to the added
    >> brittleness and non-robustness in the whole setup.

    > Actually, the main reason was to make it work on remote
    > machines. Injecting long code thorough emacs shell is very
    > unreliable. Otherwise I would definitely not have started
    > the revamp. I elaborated on this problem on ess-help
    > recently.

Indeed!  Sorry that I've already forgot about it, as honestly, 
I've never used any of ess-remote in the past
(it never worked "way back then", and nowadays, I do prefer ssh
 + start emacs on the remote, maybe it's just "bad habit").
But yes, I know how important that feature is to some of the ESS
users {and also definitely a big advantage over rstudio}.

    > [...]

    >> Yes, I feel bad about this; I've spent my several hours
    >> yesterday that are mostly lost, but of course Vitalie,
    >> you've spent more than me on this. But I strongly believe
    >> we save ourselves and even more our users much hair
    >> tearing in the future if we keep this as simple as we did
    >> in ESS 13.09.

    > Yeh ... things happen. The work is not wasted, we can
    > reuse most of it.

good :-)

    >> The small speed loss (we are talking fractions of a
    >> second anyway), could be eliminated in the future by
    >> providing optional save() and load()ing of the ESSR code.

    > Let's do this, let's roll in our own simple version
    > control system. Here is the plan.

    >  - Save ESSR environment into ESSR.rda and then attach on
    > startup. This should be instantious. So we solve the
    > loading speed problem.


    >  - On remotes we will download the binary image from a web
    > location, similarly to what we are doing now with
    > ESSR<ver>.tar.gz. Then save it in ~/.config/ESSR/ESSR.rda
    > and ~/.config/ESSR/version. On next load we check for
    > "version" and re-download when outdated.

sounds very good.

Note that Windows (in the past at least) sometimes, i.e., for
some users, had problems determining the home directory, or is
also known to sometimes have problems in creating directories,
but let's hope we can divert here to R which has basically
solved this, too, e.g. in install.packages()  

    >  - If loading fails, for whatever reason, we use
    > ess--inject-code-from-file as we did in 13.09. This will
    > assure that the stuff works on very old R and if download
    > failed.

yes. Some things still fail on very old R (and did in 13.09 already),
but maybe there are only 1--3 people in the world who will be affected.
As I am one of them, I will try to tweak our R code a bit further,
but I assume I'll have no chance of parsing code with "::" in it
in R versions before NAMESPACEs.
But all that is not release show-stopping.

    > This is almost identical to what we have now, it should
    > not take more than a couple of hours to adjust.

that sounds great.

    > Martin, how far backward compatible save and load is? Can
    > you please check this part?
    >    Vitalie

Yes, I'll do some experiments shortly.
But also, in any case should not be "release show stopping"
(I think at the moment ..)

Martin