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

[Richard M. Heiberger]

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.

Rich

From: ESS-help <ess-help-bounces using r-project.org> on behalf of Kevin R. Coombes via ESS-help <ess-help using r-project.org>
Date: Wednesday, July 13, 2022 at 11:16
To: Shreyas Ragavan <shreyas using fastmail.com>
Cc: ess-help using r-project.org <ess-help using r-project.org>
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?

Best,
   Kevin

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 64bit.
>>>>
>>>> On operating systems that use $PATH you can _always_ just point to a working
>>>> R by pointing RHOME/bin so that the right R is found. It has been years since
>>>> I worked on Windows but it got the R I wanted when I told ESS in no uncertain
>>>> terms which one I wanted. It seems to me you would be well advised to try the
>>>> same if you have confusing choice of multiple R versions to confuse ESS with.
>>
>

        [[alternative HTML version deleted]]

______________________________________________
ESS-help using r-project.org mailing list
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fess-help&data=05%7C01%7Crmh%40temple.edu%7Cf3c7faee52134b6d990d08da64e2a99e%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637933221930265828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jTseke520ToUSsTiWy%2FVJwzWWQXp%2B3Z2ZesO29G67wk%3D&reserved=0

	[[alternative HTML version deleted]]