Re: [ESS] [External] Re: ESS confused about newest R

2022-07-13 Thread Stephen Eglen via ESS-help
> For me, that now starts R 4.2.0 on WIndows.
> However, given the fragility of regexps, does anyone (Martin?) know why
> the ucrt now appears in versions on Windows, and whether that was
> deliberate?  ESS might well be the only program that machine reads that
> date, but still we should try to future-proof this or find out if it was
> a bug that crept in.  It looks odd to me, since UCRT seems to be short
> form for 'Universal C Runtime'.

Reading R news shows the switch to UCRT  as the new C runtime on
windows.  So it is probably a deliberate addition into the version

__ mailing list

Re: [ESS] [External] Re: ESS confused about newest R

2022-07-13 Thread Richard M. Heiberger via ESS-help
The change in date format makes sense.  The short term workaround is to set the 
specific R you want.

In general, that ESS code on Windows was designed to find R in any of a number 
of standard places.   The list of what
those standard places are is also a variable you can set.  The details have 
been changed since I wrote it, so someone
more current will need to verify and modify the code.


From: ESS-help  on behalf of Kevin R. Coombes 
via ESS-help 
Date: Wednesday, July 13, 2022 at 11:16
To: Shreyas Ragavan 
Subject: [External] Re: [ESS] ESS confused about newest R
*Latest Follow-up*

I think I have found the offending code in "ess-r-mode.el". The critical
function appears to be "ess-r-version-date". This function actually runs
the Rterm.exe for each version of R (who knew?) that it located, using
the "--version" command line argument. It then parses the version line
to find the actual release date. Starting with R-4.2.0 (at least on
Windows), that line has changed from the previous form:
   R version 4.1.0 (2021-05-18) -- "Camp Pontanezen"
to something like:
   R version 4.2.0 (2022-04-22 ucrt) -- "Vigorous Calisthenics"
Note in particular the extra " ucrt" in the parenthetical display of the
date. I strongly suspect that the regexp being used to parse the date
fails to recognize this new form.

I am also 100% certain that I cannot rewrite the regexp to work in this
setting without breaking something else, since it is carefully and
complexly designed to parse *all* of the version-date lines going back
to R 1.0.1.

To whom and where should I report this as a bug in order to encourage
one of the ESS gurus to see if my conjectured explanation of the bug is
correct and (I hope) manage to fix it?


On 6/29/2022 1:24 PM, Kevin R. Coombes wrote:
> Follow-up:
> I just installed the latest emacs (28.1) and used MELPA to install the
> latest version of ESS (20220621). With this new setup, I still have
> the same problem. ESS/R finds all versions of R on my system, and
> generates separate commands for each one (including the newest,
> R-4.2.1-64bit. However, R-newest thinks that the newest version I have
> is R-4.1.0, and so the command "M-x R" starts the 64bit version of
> R-4.1.0.
> To test my hypothesis that this has something to do with 32-bit vs
> 64-bit, I tried the following experiment. I created a folder
> "bin/i386" inside my R 4.2.1 installation, and copied R.exe and
> Rterm.exe from the R-4.1.0 installation into that folder. Now when I
> try to run R, it finds both the real R-4.2.1-64bit and my fake
> R-4.2.1-32bit. But (damnit) it still runs R-4.1.0 as though it were
> the newest version. So, I have no idea if 32bit is a red herring or
> not, and I am mightily confused about why ESS doesn't seem to like
> R-4.2.1.
> On 6/29/2022 11:18 AM, Kevin R. Coombes wrote:
>> To clarify, I don't ever start R (as Rterm) from a  command line
>> prompt on Windows. As a result, I really don't bother to put the R
>> installation location into the PATH environment variable, since I
>> don't want to have to update it every time a new version is released.
>> (For the same reason, I don't want to have to manually set
>> "inferior-ess-r-program" and have to remember to update it with new
>> releases.)
>> I have desktop icons for the RGui. I can see the version number and
>> name on those icons if I want to start R that way; those all work. I
>> also have no problem using RStudio, which continues to be successful
>> in automatically finding the newest versions. The only problem is
>> with ESS inside of emacs, and it started with version 4.2.0, which
>> coincided with dropping the creation of 32-bit R versions on Windows.
>> Further, ESS/R does *find *all versions of R on my system. I know
>> this because it creates separate startup commands (such as
>> R-4.2.0-64bit). That part that fails is the code in the file
>> "ess-r-mode.el" that is supposed to find the newest R from the list
>> of all available versions.
>> On 6/29/2022 9:57 AM, Shreyas Ragavan wrote:
>>> I wanted to add a suggestion here that when or if you add multiple R 
>>> versions from non-standard paths to your PATH environment variable in 
>>> Windows (to enable Emacs or any program to find the R executable) - it is 
>>> important to make sure the desired version of R is the First path. Programs 
>>> will stop looking for the executable once it is found, and if an earlier R 
>>> version is found before the desired version - that is what would start up.
 Your (from description) Windows system appears confused about where to find
 R, and doubly so as a 32/64 bit convention is dead, and there is only 

 On operating systems that use $PATH you can _always_ just point to a 
 R by pointing RHOME/bin so that the right R is found. It has been years 
 I worked on Windows but it got the R I wanted when I told ESS in no