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

[Vitalie Spinu]

Ok then, I will try to adjust the code today so that from tomorrow we
are back on track for the release.

I will need you help on automatically building ESSR images. Let's hope
we don't have more surprises. For a couple of days I will switch back to
hosting them on my page.

  Vitalie

 >>> Martin Maechler on Thu, 31 Oct 2013 17:52:20 +0100 wrote:

 > 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