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

I wrote the original code for finding other versions of R, cripes, about
20 years ago.  Let me look at what is going on.  I have access to
windows, so let me look into it.




On Wed, Jul 13 2022, Richard M. Heiberger via ESS-help wrote:

> 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 <[email protected]> on behalf of Kevin
> R. Coombes via ESS-help <[email protected]>
> Date: Wednesday, July 13, 2022 at 11:16
> To: Shreyas Ragavan <[email protected]>
> Cc: [email protected] <[email protected]>
> 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]]
>
> ______________________________________________
> [email protected] mailing list
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fess-help&amp;data=05%7C01%7Crmh%40temple.edu%7Cf3c7faee52134b6d990d08da64e2a99e%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637933221930265828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=jTseke520ToUSsTiWy%2FVJwzWWQXp%2B3Z2ZesO29G67wk%3D&amp;reserved=0
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> [email protected] mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help

______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help