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

[Vitalie Spinu]

Done. Ess-remote and tramp work smoothly in my tests. I also fixed a
long standing issue with the pager="cat" on remotes. Would appreciate if
people could test.

To test ess-remote you don't need a remote. Just start *shell* then R,
then M-x ess-remote.


Martin, I commented out ESSR make targets and made an Rscript to build
ESSR_<version>.rda. Please see ESSR/VERSION and ESSR/BUILDESSR. You
shold also check ESSR/LOADREMOTE which is used for loading of our code
on remotes. Please change the url once you have setup the
auto-build. Thanks.


 Vitalie



 >>> Vitalie Spinu on Thu, 31 Oct 2013 15:49:47 -0700 wrote:

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

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

 VS>   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