[ESS] Install experiences
Frede Aakmann Tøgersen
frtog at vestas.com
Fri Nov 29 08:06:48 CET 2013
I repost this since it didn't get through to the list first time.
Sorry for the inconvenience.
;; My emacs didn't have string/starts-with function used in this implementain so googled for this
;;(defun string/starts-with (s begins)
;; "returns non-nil if string S starts with BEGINS. Else nil."
;; (cond ((>= (length s) (length begins))
;; (string-equal (substring s 0 (length begins)) begins))
;; (t nil)))
I can do this using the w32reg-read-key function, which returns a list (KEYNAME VALUES SUBKEYS)
(setq all (w32reg-read-key "hklm\\software\\R-core\\R32")) ; 32 bit version
(setq all (w32reg-read-key "hklm\\software\\R-core\\R")) ; 64 bit version ??
(setq all (w32reg-read-key "hklm\\software\\\wow6432Node\\R-core\\R")) ; 64 bit version
They all gives the same list except for different KEYNAME. The return value looks like this:
all's value is ("HKEY_LOCAL_MACHINE\\software\\wow6432Node\\R-core\\R"
(("Current" "Version" "REG_SZ 3.0.0")
("InstallPath" "REG_SZ" "C:\\Programmer\\R\\R-3.0.0"))
("3.1.0 Pre-release" "3.0.2" "3.0.0"))
Initially I only had R-3.0.2. Installing the devel version 3.1.0 Pre-release it became current version. Then installing R-3.0.0 this became the current version. So it seems that the last installation becomes the current one. I believe that one can from the returned list get a list of paths to installed R versions. That is, in the case that R core do not change the structure on the R installation folders. I believe there will be some differences between recent versions of R and older versions.
As you can see from the value of the list 'all' then my R installations go to a non-default folder without spaces. What happen if I additionally install R-3.0.1 in default folder suggested by the install program?
Here we get this value of all:
all's value is ("HKEY_LOCAL_MACHINE\\software\\R-core\\R"
(("Current" "Version" "REG_SZ 3.0.1")
("InstallPath" "REG_SZ" "C:\\Program Files\\R\\R-3.0.1"))
("3.1.0 Pre-release" "3.0.2" "3.0.1" "3.0.0"))
Now the InstallPath points to the latest installation. This folder only have the 3.0.1 version. Now we can't from this get access to the 3 other installations.
However we can subsequently loop over the SUBKEYS, e.g. for first SUBKEY:
(setq all (w32reg-read-key "hklm\\software\\R-core\\R\\3.1.0 Pre-release"))
all's value is ("HKEY_LOCAL_MACHINE\\software\\R-core\\R\\3.1.0 Pre-release"
(("InstallPath" "REG_SZ" "C:\\Programmer\\R\\R-devel"))
So this way we can get the paths if there is the required information in the registry database. This needs not be the case because during installation of R on Windows you will be asked for instance whether you want the installation program to write to the registry database. See the screen dump below (in case picture is being stripped from mail see https://drive.google.com/file/d/0B8PLINArwEPcWnNjN2l1ZHlvdUk/edit?usp=sharing). Per default both registry entries are check marked. Only if someone do uncheck version number in registry nothing will be written to the database.
So should we in that case try to use R.bat to find R folders. I do not have any of my R versions in my path so I get this when issuing "R.bat show":
Having e.g. C:\Programmer\R\R-3.0.0\bin\x64 in path gives:
So supposing that a user have all the R versions in path we can the information we want.
Using some kind of heuristics to search for R version on a number of drives seems not to be the way. If the user has access to a number of potentially large network drives or several local drives this will be quite annoying and time consuming.
My suggestion will be to use only the registry database. In case a user with emacs/ESS installed do not have entries in the database then issue a warning about making sure that R in the first placed was installed and secondly that the save version number in registry was check marked.
My elisp skills are very rudimentary so forgive me that I have not coded a full blown version; it will take too much time. However I believe that some of the core people can easily wrap things up in a nice way.
Should you however need me for testing new code on a Windows machine I will be happy to help.
Yours sincerely / Med venlig hilsen
Frede Aakmann Tøgersen
Specialist, M.Sc., Ph.D.
Plant Performance & Modeling
Technology & Service Solutions
T +45 9730 5135
M +45 2547 6050
frtog at vestas.com
Company reg. name: Vestas Wind Systems A/S
This e-mail is subject to our e-mail disclaimer statement.
Please refer to www.vestas.com/legal/notice
If you have received this e-mail in error please contact the sender.
> -----Original Message-----
> From: ess-help-bounces at r-project.org [mailto:ess-help-bounces at r-
> project.org] On Behalf Of Vitalie Spinu
> Sent: 28. november 2013 03:52
> To: Paul Johnson
> Cc: Richard M. Heiberger; ess-help at r-project.org
> Subject: Re: [ESS] Install experiences
> >>> Paul Johnson on Wed, 27 Nov 2013 19:54:29 -0600 wrote:
> > Concerning reading the registry, I expect that Gabor Grothendieck knows
> > to read the registry to get the R location. We could learn how this is done
> > from the source code for NPPTOR and/or RStudio. They both manage it. I
> > notice that RStudio seems to get it right, almost invariably, while NPPTOR
> > is only about 70% right.
> It looks like we are talking more than doing on this issue for 2 years
> already. It is just one system call, isn't it?
> It is really unfortunate that almost all ESS core developers are Windows
> illiterates, but what can we do about it?
> So please, could someone with bare minimum of knowledge of windows batch
> scripting look into Gabor's script at
> https://batchfiles.googlecode.com/svn/trunk/R.bat and isolate the system
> call that retrieves R location from the registry?
> Let's solve this issue once and forever.
> ESS-help at r-project.org mailing list
More information about the ESS-help